 |
|
//TITLE: Cracking Nags. A Diffinative Guide.
//BY: n0p3x
//EMAIL: adminno1@yahoo.com
//WEB: http://cod3r.cjb.net
//FOREWORD
The method we will use to destroy the nag is quite unusual but guaranteed to work on all nag screens that use a button to dispose of them. With a bit of thought the information learned from this tutorial can be modified to suit many other occasions.
This is a pretty stupid way of killing a nag screen as their are many easier ways but the theory behind this method is very usefull.
//WHAT WE WILL DO
We will let the nag display as usual. We will then add our own code directly after the loading of the nag that sends a message to the okay button (the button that disposes of it) and tells it to act as if it had been clicked. The program will then call its own nag ending routine and it will be gone. Theoretically the nag will still be displayed, but it will also be destroyed straight away so dependant on the speed of the computer you shouldnt even see it.
//FINDING A HOME FOR OUR CODE
The code to send a quit message to our dialog could be quite long so we are going to have to modify the size of the program so we can fit our own code in. If you open the file with HIEW you'll have all the infomation you need to add you own code. As you know, we can't occupy MORE bytes than the ones we have in the actual code (which resides in .TEXT section), so we are compelled to APPEND our code to the end of the file, so that afterwards we will be able to redirect jumps from PE .TEXT section to the section where we added the code.
Usually when you want to add your own code, the last section will be just fine for the trick. So well use that. The first thing to do is check the physical space (i'm talking about BYTES) we have for our code: so we check the Virtual Size and the Physical one; the virtsize shows us the number of bytes that we can't modify, in other words the ones already used by the program, while the physsize shows us the raw size of the section: a simple subtraction PhySize-VirtSize will give us the amount of free bytes in which we will be able to add our code.
If thier is enough free memory available then you don't need to alter the size, but if their isnt enough memory free you will need to enlarge the section. You can do this in ProcDump by increasing the physical size.
Now we have our free space we need to know where it actually resides so we can enter our code their. This is easily obtained by Initial Offset + Virtual Size. This calculation will return the offset for the entrypoint of our code.
//THE ACTUAL CODE
Now we will have to descide on the code we wish to insert in the program to destroy the nag. Unfortunately this is a little more dificult than it sounds but im sure we'll manage :-).
The main problem we have is if the function SendDlgItemMessage is not included in the import table. I will assume it isnt. I will also assume that the functions getmodulehandlea and getprocaddress are in the import table as most compiled programs use these.
The problem is that we dont know the address to call to send the message. Therefore we need to obtain the address. We use getmodulehandlea to find the libraries handle, and getprocaddress to get the functions address.
A basic algorithm for the code:
{
sDLL db "user.dll",0 ;May be in kernel?
sAPI db "PostDlgItemMessageA",0
aAdd dd 0
pushad ;Save all registers
;Get the dll's handle
push offset sAPI
call GetModuleHandleA
push offset sAPI
push eax ;Handle of the DLL
call GetProcAddressA
mov sADD, eax
push 0
push 0
push WM_LBUTTONDOWN
push OKAY_BUTTON_ID
push DIALOGS_HANDLE
call sAdd
push 0
push 0
push WM_LBUTTONUP
push OKAY_BUTTON_ID
push DIALOGS_HANDLE
call sAdd
popad
jmp Back_To_Main_Code
}
This code is getting longer and longer by the minute :-). To make the code actually work you will need to call it just after the dialog has been displayed. Imagine the following code:
{
push SOME_VALUE
push ANOTHER_VALUE
call DialogBoxParamA
ret
}
The problem with this is desciding where to shove the jump to our code AFTER the dialog has been displayed. You will need to find the part of the code that is called oncew the dialog is initialised. When the dialog initialises itself it sends a WM_INITDIALOG message. Simply set a breakpoint on this message within softICE, then when you encounter the code, find a call near the start and replace that with a jump to our code. Now in our code make sure you insert the code you removed.
The strings used in the above algorithms would all need to be added to the string table and loaded each time they are needed accordingly.
You would also need to know where to make the jump jump to our code section. This is easily done if you open your target in HIEW, select decode and goto the offset of your section. Then press 'CTLR + F1'. The offset will then change. Copy this address as this is the address you need to make the code jump to.
//THE END OF AN END
Thats more-ales it. Just a matter of calculating op codes for your asm and inserting them into the target program. When your program runs it will jump to your code, display the nag, tell it to quit straight away, and then procede with the main code.
//GREETS
-Neural_Noise - For the 'finding a home for our code' section as some of this text is stolen from his hnotepad tutorial. Also for the help with getting addresses for API's not in the import table.
-Eternal Bliss - For cracking my crackme when others gave up.
-noos - For causing kaos everytime he or someone he knows enters #cracking4newbies, and insists on greeting each other as nnnnnnooooooooooooooooossssssssss. :-)
-Carpathia - For info on Screaming.net, allthough i haven't got a copy of a BT bill ATM so i cant change over yet :-((.
-TeChNiCh - For supposibly running an 'elite' group (#digital.factory) yet not knowing what a dongle is :-/
-Carolyn - Sorry your last babe...:-()
//END BIT
Thanx for paying atention, i know there are millions of errors in this tut but plz, if you feel the nescesity to come and insult me for it then dont bother..
n0p3x [adminno1@yahoo.com]
http://cod3r.cjb.net